Access control systems have been used to impede unauthorized personnel from using the elevators to gain access to entire floors for over thirty years. Upon entering the elevator cab in an access controlled elevator, a person finds all the floor select buttons unresponsive.
A person is allowed to make floor selections after presenting an authorized credential to a credential reader within the elevator cab. The access control system, upon receiving the indicium from the credential reader, responds by releasing the floor exclusions on the set of authorized floor select buttons for that credential. The person makes their selection from this authorized set and the elevator then responds by delivering the occupants to the selected floor.
In many real estate settings, common areas and resources may be shared among several different entities. These common resources must be used to comfortably utilize the entities' private areas. For example, in an office tower, tenants share the lobby, parking areas, high volume air conditioning (HVAC), and elevators. During off hours, these common resources are restricted to authorized individuals. In the case of elevators or HVAC, only parts (partitions) of the entire building's resource may be utilized by a tenant's authorized employee. Each entity may wish access for thousands of individuals to these resources in order to comfortably access their private space. Consider a high rise office tower housing several large corporations. Those corporations could desire access for all their employees to employee amenities like an automated teller machine (ATM) or a cafeteria on an upper floor. It is common practice for each entity to equip their personnel with electronically readable credentials (coded indicia), which serve as a key to access the entities' private areas. These credentials, when used in conjunction with electrically controlled locks on the portals and computer databases, are known as card access systems. The advantages of card access systems, as taught by U.S. Pat. No. 2,714,201 Identification Selector at Column 1 lines 33-52, are well known to the owners and managers of these properties.
As these systems have proliferated, it has become common for each entity within the building to purchase their own proprietary access control systems. The owners and managers of these properties desire to accommodate each entity's desire to grant access to authorized individuals, yet deny access to all others. The property managers have essentially four choices. They could issue their own credentials to all authorized people, or allow each entity to mount their own credential reader and controls at the building portals. Other techniques require each entity to periodically share their list of authorized credentials with the property management or the entities could expose their credential databases on a common network. Each of these four techniques has significant disadvantages as described below.
Issuing everyone their own building management credential has several disadvantages. First, it requires the purchase and distribution of credentials for everyone authorized to use the common spaces afterhours. Typically, the common area credentials are incompatible with the entity's proprietary standards for credentials. Therefore, this technique often requires the individuals to carry multiple credentials. Additionally, the building management must synchronize their credential list with changes from each entity's roster. The typical implementation is a manual system of faxed or emailed paper work. A common problem with a manual system is the building's database becoming “stale” with outdated information. The result can be terminated individuals still having access to the building and newly hired individuals being denied access because the system which transmits the changes from the tenant to the building management has broken down. The results can range from inconvenience for the newly hired to a potentially dangerous situation where an aggressive terminated employee has afterhours access to the common areas.
Allowing each entity to mount their own credential reader and control system on the building portals results in an aesthetically disagreeable and confusing collage of credential readers at each of the building resource portals. It is difficult and expensive to integrate more that one access control system with partitioned resources, like elevators or HVAC systems. The expense and large number of interconnections required make ordinary integration techniques impractical. Additionally, if one of the controlling systems should fail, often the buildings resources are either locked or unlocked at the wrong times. With the portal controlled by multiple entities, the problem requires diagnostics to pinpoint the trouble source. Even knowing the source of the problem, multiple vendors must frequently be coordinated to resolve the problem. The diagnostic procedure and subsequent vendor coordination slows the repair process when compared to a single portal, single vendor solution.
If the tenant and the management can agree upon a specific credential technology, then building management can update their database of valid access credentials based on a database extraction of the tenant's system. The issue of choosing a specific credential technology has been eased by the introduction of credential readers capable of reading multiple technologies. An example of a multi-technology credential reader is taught by U.S. Patent Application Publication No. 2007/0057057 Synchronization Techniques In Multi-Technology/Multi-Frequency RFID Reader Arrays Page 1 Paragraph [0011], and embodied by the HID Model RP40 multiCLASS Reader 6125.
An example implementation of this technique was demonstrated by George Mallard's article “Future of access control tied to integration” in Access Control Magazine Volume 34, Number 10, September 1991, page one. This solution works well and addresses the aesthetic and service problems of multiple credential readers at the building portals. This technique partially addresses the “stale” database problems because the download and processing cycles are typically a batch process. The typical system has the batch run once a day, first by the entity, then by the property management. Entity credential changes done after their batch wait a full day before becoming active in the building's system. Additionally, the maintenance of the database transfer can be problematic and requires customization of both the entity's and the building management's access control systems software to accommodate the extraction and importing of each entity's authorized credential list. Finally, many companies have become reluctant to share a list of their credential holders with outside entities.
The Federal Government has addressed this same problem of authentication of credentials where several agencies need access to a shared portal. Their method of cross agency authentication is documented by the Backend Authentication Work Group prepared for the Federal Smart Card Interagency Advisory Board (IAB), “Framework for Interagency Authentication of Federal Personal Identity Verification (PIV) Cards”, August 2006. This method defines a protocol where one agency can query another agency's security database over a network. Where this method addresses the problem of multiple entity authentications, it does require each entity to expose their security database on a common network and all entities to conform to a standard protocol. On page seven of the report, the authors note that “A secure means of transporting these messages must be devised”. Further on page 12, the authors state “The most important aspect of this security (since the message payload will be encrypted) is that a gateway can trust that the message was sent by another trusted gateway”. The Federal Government has the resources to implement the security required by this technique. However, in a commercial environment, cost is a factor. Therefore, as is known to those skilled in the art, the cohabitation of databases on a common network both opens the possibility of unauthorized access to sensitive information and is expensive to implement and maintain. The standard protocol for exchange of information may not be supported by all entities, and therefore requires expensive modifications to their access control systems. These factors make the common protocol choice unattractive for commercial users.
The reader communicates the alphanumeric code read from the individual's credentials to the control panel utilizing serial data, clock plus data, or the Weigand interface well known to those skilled in the art. Serial data is sent using an interface standard such as defined by the RS485, RS232, RS422 or other standard. The Weigand interface was defined by Sensor Engineering in the early 1980's and is documented in the HID application note AN004.DOC prepared by Eric Sprik Sep. 21, 1998 page 9.
Tech Tip #5 within Mr. Sprik's AN004.DOC page 11 discusses the structure of a common indicia coding. A coding example is shown in FIG. 3A and FIG. 3B. A credential with an indicium facility code of 159 and a personal identification number of 2199 are illustrated in both Figures. This coding has 26 binary digits, or bits, formed from the two parity bits (301, 304), the eight facility code bits (302), and the sixteen personal identification number bits (303).
Refer to FIG. 3A to understand the error checking. The first parity bit (301), is set so that the count of bits with a value of 1 in the combined set of the parity bit (301), and the first twelve significant bits (307) is an even number, in this case six. This scheme is known as “even parity”.
The second parity bit (304), is set so that the count of bits with a value of 1 in the combined set of the parity (304), and the last twelve significant bits (306) is an odd number, in this case seven. This scheme is known as “odd parity”. Parity is used to insure the coding was correctly read from the credential.
Refer to FIG. 3B to understand the structure of the indicia coding. The eight bits used for the facility code (302) defines a set of two hundred and fifty-six unique facility codes. In FIG. 3B (302), the facility code shown is 159. The sixteen bits of the personal identification number (303), defines a set of sixty five thousand, five hundred and thirty-six unique personal identification numbers. In FIG. 3B (303), the personal identification number is 2199.
An entity's facility code distinguishes their credentials from those belonging to other entities. Consider telephone numbers. A person in Houston could have the same seven digit phone number as someone in New York. But, the area codes make the phone number unique. In the same manner, a twenty six bit credential from entity A may have the same personal identification number as someone from entity B. The facility codes make the credentials unique. Since this twenty-six bit coding scheme was devised by Sensor Engineering in the late 1970's, the success of access control equipment has outdated the twenty-six bit coding scheme.
Schemes with many more bits, both for the facility codes and the personal identification number, have been devised which allows the manufacturer to enter into agreements that allow the entities to “own” their facility codes. This practice is documented in the 2005 HID white paper “Understanding the Corporate 1000” page 1. It should also be noted that some of these newer schemes have more parity bits and/or error checking and correction bits known to those skilled in the art. Essentially, any of the techniques used for error checking and/or correction in serial data transmission can be employed for the credential indicia, for example Cyclic Redundancy Checking.
Elevators are a portal through which tenants pass to access their private spaces. Security methods have been devised to limit use to preauthorized sets of floors. One method simply treats the ground lobby “Hall Call” button that summons an elevator to the floor as a control point. A card reader is associated with the button preventing its use without an authorized credential. Elevators frequently service more than one tenant. This method does not prevent one tenant from accessing another tenant's floor serviced by that same elevator.
A better method for implementing securing elevators is to view them as a partitioned resource, each floor being a partition element. The addition of access control system relays, one for each floor select button, implements the partitioning system. When inactive, the associated floor select button is unresponsive. Upon reception of an authorized indicium, the access control system activates the set of relays corresponding to the floors authorized for that credential. This allows the credential holder to register his request to the elevator control machinery by pressing one of the now responsive floor select buttons. Pressing a floor selection associated with an inactive button will not register with the elevator control machinery.
Referring to FIG. 2A, the individual (200) approaches resource portal (elevator cab) (209) and presents his credentials to reader (201). The electrically encoded identification is transmitted to control panel (202) via connection (106). The panel (202) then formats this identification into a message and transmits it to the monitoring computer (204) via communication line (203). This message is received by the computer (204) which processes the message. The computer (204) consults a database of authorized users returning a message that authorizes access to the appropriate portions of the resource. The resource partitioning panel (208) receives the message from communication line (105), activating appropriate relays FIG. 2C (211a through 211n) within resource partitioning panel (208). Each relay FIG. 2C (211a through 211n) corresponds to a partition of the resource. In the example of an elevator control system, the resource partitions correspond to floors. A floor selection will only be registered as a floor call by the elevator machinery if the associated relay FIG. 2C (211a through 211n) is active.
Referring to FIG. 2B, the resource selection panel (214) is illustrated for an elevator. The floor select buttons (210a through 210n) are mounted on the resource selection panel (214). The credential holder FIG. 2A (200) closes the associated electrical contact FIG. 2C (210a through 210n) by pressing the button.
Referring to FIG. 2C, the resource partitioning panel (208) circuitry is illustrated controlling access to the resource, elevator floor selections. The floor select buttons (210a through 210n) are normally open pushbuttons. The partitioning relays (211a through 211n) normally open contacts are wired in series with the floor select buttons (210a though 210n). The elevator machinery control (212) registers a closure on the floor select inputs (213a through 213n) as a floor call and responds by delivering the occupant (200) to the corresponding floor. When secure, closure of the floor select button (210a through 210n) is not seen by the elevator machinery control inputs (213a through 213n), because the circuit is open at the inactive partitioning relays (211a through 211n). Thus, the partitioning panel (208) prevents floor requests from being registered. When the occupant (200), who is a credential holder, presents a valid credential to the credential reader (201), the access system responds by activating only those partitioning relays (211a through 211n) corresponding to the subset of floors the credential holder is authorized to access. The selected partitioning relays (211a through 211n) are active for the period of time deemed sufficient for the credential holder to make his selection. The partitioning relays (211a through 211n) outside of the subset are not active. Thus, the floor select buttons not included in the subset are not responsive. Some of the newer elevator machinery controls provide specific partitioning relay inputs. Software within the elevator machinery controls effectively places the partitioning relays (211a through 211n) in series with the floor selection buttons (210a though 210n).
The number of floor select buttons in high rise elevators frequently exceed the relay capacity of common access control panels. Often, the resource partitioning panel (208) is implemented as independent controller. The Optomux controller, manufactured by Opto22 of Temecula, Calif., has the capacity for an array of up to sixteen relays. Should an elevator require more than sixteen control relays, multiple Optomux panels may be grouped implementing a larger resource partitioning panel (208). A string of ASCII characters controls the Optomux. Received from an RS-485 or Ethernet circuit, the string indicates which relays are to be active and for how long. When an indicium is presented to the reader (201), the access control system computer (204) responds with a string appropriate for that credential. This string is directed to the resource partitioning panel (208). The resource partitioning panel (208) activates the predefined subset of floor select relays (211a through 211n), as directed by the aforementioned string. Only then is the credential holder is free to make their floor selection. Because only the predefined set of floor selection buttons are active, the credential holder selection is limited to that set. After a short period of time, a typical value being 15 seconds, the floor select relays (211a through 211n) are de-activated, securing the floor select buttons.
It should be noted that U.S. Pat. No. 4,644,484 Stand-alone access control system clock control at Column 2 lines 38-41 teaches that the cardholder database can be incorporated within the control panel (202). By extension, cardholder's authorized resource partition control strings are also included in some control panels.
The Laredo interface, as produced by KMS Systems, Inc., which was demonstrated to the public at TechSec in Dallas February 2007, incorporated certain features used in the present invention. However, the Laredo system presented did not incorporate the “Virtual Card Read” described below.
A method to extend credential reader signals point to point over a network is illustrated by the Cypress Computer Systems, Inc. single reader extender model SIO-7200. As described on page one of the Cypress Computer System user manual, the 7200 series is a paired central and remote point to point network devices. The Nov. 18, 2004 setup document further illustrates this with the central device's IP address requiring the remote device's IP to be entered in the setup, page 8. Similarly, the remote device's IP is required when setting up the central device. In contrast to a point to point system, the invention described herein is a multipoint network system.
The DataBender™ series of manufactured by Cypress Computer Systems, Inc. mutate a credential indicium from one bit structure and/or electrical format to another, preserving the indicium personal identification number as best it can. The CVX-1201 and the CVX-1200 offers test modes where predefined indicia are output. However, the DataBender™ output is not under the control of an external input. Instead, it simply reformats the input indicium into the same indicium represented in a different format. The DataBender™ output is not a network message routed to the originating panel from a plurality of potential panels. Nor can the DataBender™ test indicium output be adjusted. The present invention described below uses an external contact's active state to control the generation of a predefined pseudo-credential message within a sequential framework of outputting the original credential and waiting for a response within a certain time frame. That pseudo-credential message is reflected back into the originating panel from a plurality of possible originating panels. The pseudo-credential message, in certain cases, retains the Facility Code of the original indicium.
This invention differs from a distributed database system, as taught by U.S. Pat. No. 5,721,909 Distributed Database Architecture and Distributed Database Management System for Open Evolution at Column 1 lines 32-40. Specifically, this invention lacks point 3 (“true database not a collection of files that are stored at each node”) and point 4 (“the full functionality of a database management system”). In the present system, each entity manages their own list of credentials, the system is a collection of independently managed files. No relationship or linkage exists between the entities' lists of credential holders. In the present systems by design, there is no mechanism or administrator feature that would allow a single entity to manage all the access control system's databases.